Blink.ino before:
Program size: 257,740 bytes (used 25% of a 1,044,464 byte maximum) (1.99 secs)
Minimum Memory Usage: 26548 bytes (32% of a 81920 byte maximum)

After:
Program size: 257,356 bytes (used 25% of a 1,044,464 byte maximum) (22.41 secs)
Minimum Memory Usage: 26532 bytes (32% of a 81920 byte maximum)

@d-a-v @devyte Please review?

@hreintke What do you think? Could you please check the FunctionalInterrupt/library.properties?

@d-a-v @earlephilhower @devyte This is 3 weeks old, and I am sorry, had gotten out of control somehow, being a PR containing a lot of unrelated changes.
I've cleaned up now to the minimum changeset, and I would like to ask you again to review and consider merging, possibly ahead of #6214 , which I personally am having a bit of a hard time figuring out what the rationale is, nevermind.

@d-a-v #6214 , why o' why...
The explanation isn't quite comprehensive yet. I disagree with the wording "long running operations or yield() or delay() are NOT WISE in the lambda." - should be either a yes or a no, nothing indeterminate.
I think it's a mistake not allowing one-shot scheduled functions to run on yield now - an async programming style produces much slower or un-responsive sketches this way. And this just because yields are not allowed? One-shot functions don't have to be slower than recurrent ones to contain yields - are the scheduled interrupts not hampered now for no good reason at all?

But of course my biggest gripe is that all my PRs need intensive care now 👎

I think it's a mistake not allowing one-shot scheduled functions to run on yield now - an async programming style produces much slower or un-responsive sketches this way.

I agree. I did what the majority told me.

In some other comment it was clearly stated that scheduled functions should be allowed to run delay() and yield(), plus the fifo semantic, plus once per loop. I did my homework. This doesn't fit my (ethernet) needs so I added the recurrent version.

You can however use recurrent scheduled function like you do with scheduled function with

• return false
• ::alwaysExpired polledTimeout parameter.
• without fifo semantics

@d-a-v I'll see what I can do to the circular-queue based scheduler. First, I'd like to see the EspSoftwareSerial issue (#6227) through, the attachInterrupt fix/improvement is important (#6047 does away with #6055 and #6048 in one step), and getting this here pluggability into core would be awesome.

@d-a-v

You can however use recurrent scheduled function like you do with scheduled function with

return false
::alwaysExpires polledTimeout parameter.
without fifo semantic

Oh wait a minute - is this a suggestion for scheduled ISRs? Doing those without FIFO semantics is completely wrong.

It's not a suggestion for scheduled ISR, there are conditions if you wish to do that, and one of them is "without fifo semantics".

Oh wait a minute - is this a suggestion for scheduled ISRs? Doing those without FIFO semantics is completely wrong.

Now if you think scheduled ISR should be called also from yield, fifo semantics needs to be added to recurrent scheduled functions, which will increase overhead, which was an argument against the previous implementation.

(see? I do my homework)

@d-a-v What's in master now doesn't work, I am sorry. Regression test using f5a882d is OK.

ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vb20cfcf5
~ld

Just running ScheduledFunctional.ino , then clicking button 2:

#include <FunctionalInterrupt.h>

#ifndef IRAM_ATTR
#define IRAM_ATTR ICACHE_RAM_ATTR
#endif

#if defined(ESP32)
#define BUTTON1 16
#define BUTTON2 17
#elif defined(ARDUINO_ESP8266_WEMOS_D1MINI)
#define BUTTON1 D4
#define BUTTON2 D3
#else
#define BUTTON1 2
#define BUTTON2 0
#endif

class Button {
  public:
    Button(uint8_t reqPin) : PIN(reqPin) {
      pinMode(PIN, INPUT_PULLUP);
      attachScheduledInterrupt(PIN, [this](const InterruptInfo & ii) {
        Serial.print("Pin ");
        Serial.println(ii.pin);
        buttonIsr();
      }, FALLING); // works on ESP8266
    };
    ~Button() {
      detachInterrupt(PIN);
    }

    void IRAM_ATTR buttonIsr() {
      numberKeyPresses += 1;
      pressed = true;
    }

    static void IRAM_ATTR buttonIsr_static(Button* const self) {
      self->buttonIsr();
    }

    uint32_t checkPressed() {
      if (pressed) {
        Serial.printf("Button on pin %u has been pressed %u times\n", PIN, numberKeyPresses);
        pressed = false;
      }
      return numberKeyPresses;
    }

  private:
    const uint8_t PIN;
    volatile uint32_t numberKeyPresses = 0;
    volatile bool pressed = false;
};

Button* button1;
Button* button2;


void setup() {
  Serial.begin(115200);
  Serial.println("FunctionalInterrupt test/example");

  button1 = new Button(BUTTON1);
  button2 = new Button(BUTTON2);

  Serial.println("setup() complete");
}

void loop() {
  button1->checkPressed();
  if (nullptr != button2 && 10 < button2->checkPressed()) {
    delete button2;
    button2 = nullptr;
  }
}

What's in master now doesn't work, I am sorry.

That one was hairy. It will be fixed by #6233 (I hadn't retested after change from malloc to new to malloc).

@d-a-v Can you help me? Where's the discussion that led to implementing two separate lists for immediate and timed scheduled functions? Was there any proof of the efficiency of this? Is anybody in any way looking at my work with the lock-free data structure and using the timer for longer delays at all right now?

Withdrawing this PR - existing Scheduler in core has received patches, works nicely, belongs in core.